Execution of a workflow that involves applications or services of data centers

ABSTRACT

A service exchange includes an orchestrator to execute a workflow that involves a plurality of applications and services of a plurality of data centers. A message broker is to exchange messages between the orchestrator and the applications. Adapters are to perform protocol and interface translations for information communicated between at least some of the applications and the message broker.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit under 35 U.S.C. §119(e) of U.S.Provisional Application No. 61/913,799, filed Dec. 9, 2013, which ishereby incorporated by reference.

BACKGROUND

An enterprise may employ multiple applications to perform various tasks.The tasks can be performed by various applications, and in some casesmultiple applications can perform overlapping tasks. As an example, thetasks can include tasks associated with information technology (IT)management, such as management of development and production of programcode, management of a portfolio of products or services, supportmanagement, IT service management, cloud and Software as a Service(SaaS) service management and so forth. IT management performsmanagement with respect to components of an IT environment, where thecomponents can include computers, storage devices, communication nodes,machine-readable instructions, and so forth. Various aspects of ITmanagement can be modeled by an Information Technology Infrastructure(ITIL) (that provides a set of best practices for IT management), aBusiness Process Framework (eTOM) from the TM Forum, and so forth. Withadvancements in IT management technology, new IT management processeshave been introduced, such as self-service IT, IT as a service provider,DevOps and autonomous IT, and so forth.

BRIEF DESCRIPTION OF THE DRAWINGS

Some implementations are described with respect to the followingfigures.

FIG. 1A is schematic diagram of an example arrangement including datacenters according to some implementations.

FIG. 1B is a block diagram of a gateway according to someimplementations.

FIG. 2 is a block diagram of a service exchange according to someimplementations.

FIG. 3 is a block diagram of a service exchange that interacts with alegacy integration framework, according to further implementations.

FIG. 4 is a flow diagram of a process of a service exchange according to

FIG. 5 is a block diagram of an example computer system according tosome implementations.

DETAILED DESCRIPTION

Workflows performed by an enterprise can involve the use of a number ofapplications. An “enterprise” can refer to a business concern, aneducational organization, a government agency, an individual, or anyother entity. A “workflow” can refer to any process that the enterprisecan perform, such as a use case. Such a process of the workflow can alsobe referred to as an “end-to-end process” or an “enterprise process”since the process involves a number of activities of the enterprise fromstart to finish. A “use case” can refer to any specific business processor other service that an enterprise desires to implement. An“application” can refer to machine-readable instructions (such assoftware and/or firmware) that are executable. The application caninclude logic associated with an enterprise process, which can implementor support all or parts of the enterprise process (or processes). Anapplication can be an application developed by the enterprise, or anapplication provided by an external vendor of the enterprise. Anapplication can be provided on the premises of the enterprise, or in thecloud (public cloud or virtual private cloud), and the application canbe a hosted application (e.g. an application provided by a provider overa network), a managed service (a service managed and/or operated by athird party that can be hosted or on premise), or a software as aservice (SaaS) (a service available on a subscription basis to users),and so forth. In some cases, multiple applications used by theenterprise may be provided by different vendors.

Within a portfolio of applications used by an enterprise, manyapplications may not be able to directly interact with each other. Ingeneral, an application implements a particular set of business logicand is not aware of other applications that are responsible forperforming other processes. The design of the application may or may nothave taken into account the presence of other applications upstream ordownstream (with respect to an end-to-end process). This is especiallytrue for older (legacy) applications. More recently, applications can atleast expose well defined application programming interfaces (APIs) thatassume that the applications will be interacting with other systems.Such applications are called by their APIs or can call other APIs. Evenwith such APIs, applications may not readily interact with each other.Different applications may employ different data formats, differentlanguages, different interfaces, different protocols, and so forth.

Application developers have developed a portfolio of applications thatrely on using point-to-point integration to provide some level ofintegration across the portfolio. With point-to-point integration, agiven application is aware of another application in the portfolio thatis upstream or downstream of the given application. Such applicationsare mutually aware of each other.

A point-to-point integration mechanism can include a component (ormultiple components) provided between applications to perform datatransformations, messaging services, and other tasks to allow theapplications to determine how and when to communicate and interact witheach other.

Different point-to-point integration mechanisms can be provided fordifferent subsets of applications. If there are a large number ofapplications in a portfolio of applications used by an enterprise, thenthere can be a correspondingly large number of point-to-pointintegration mechanisms.

As applications evolve (e.g. new release of an application, newfunctionality added to an application, variation of the expected usecases, variation of interaction to take place between applications),corresponding point-to-point integration mechanisms may have to bemodified and/or re-tested. Modifying or re-testing an integrationmechanism between applications can be a time-consuming and costlyexercise, particularly if there are a large number of integrationmechanisms deployed by the enterprise. This exercise can rapidly becomea complex combinatorial exercise. If point-to-point integration is used,an enterprise may be hesitant to upgrade applications, to add newapplications, to change application vendors, or to modify processes,since doing so can be complex and costly. However, maintaining a staticportfolio of applications can prevent an enterprise from being agile inmeeting evolving demands by users or customers of the enterprise. If anenterprise has applications provided by multiple vendors, additionalchallenges may arise. The application can be built to support updatedreleases of other applications, which adds complexity to applicationdevelopment if an enterprise wishes to deploy another release of anapplication of another vendor.

In accordance with some implementations of the present disclosure, aservice exchange and integration framework (referred to as a “serviceexchange” in the ensuing discussion) is provided that is able tointegrate applications in a flexible manner, and orchestrate executionof workflows (which can refer to enterprise processes or use cases asnoted above). Applications are used to implement their respective logicparts of each workflow. These applications are orchestrated to automatethe end-to-end enterprise process or use case.

According to the present disclosure, orchestrating execution of aworkflow can refer to modeling and executing the logic of sequencing ofthe tasks of the workflow. Some of the tasks of the workflow aredelegated using the orchestration to be performed by the logic of theapplications. As an example, a workflow can include an order fulfillmentworkflow. An order fulfillment workflow can include the following tasks:receive an order from a customer, determine applications that are to beinvolved in fulfilling the order, invoke the identified applications tofulfill the order, and return a status (e.g. confirmation number orinformation to further manage the order, such as to view, update,cancel, or repeat the order) to the customer. Note that the foregoingexample order fulfillment workflow is a simplified workflow thatincludes a simple collection of tasks. An actual order fulfillmentworkflow may involve many more tasks.

In some cases, a workflow can involve processes of applications inmultiple data centers or in the cloud or over the internet. A “datacenter” can refer to an arrangement of resources (including computingresources such as computers or processors, storage resources to storeinformation, communication resources to communicate information, andmachine-executable instructions such as applications, operating systems,and so forth). A data center can be provided by an enterprise. A datacenter can also be a public cloud, a private cloud, or a hybrid cloudthat is made up of a public cloud and a private cloud. A public cloudcan be provided by a provider that is different from the enterprise. Aprivate cloud can be provided by the enterprise. A data center is“provided” by a provider (enterprise or other provider) if the providermanages the resources of the data center and/or makes available theresources of the data center to users, machines, and/or program code.Multiple data centers can be coupled over a private network and/or overa public network such as the Internet.

A “cloud” can refer to an infrastructure including resources that areavailable for use by users. The resources of a public cloud areavailable over a public network, to multiple tenants (or customers), whoare able to subscribe or rent some share of the public cloud resources.In some cases, a public cloud provided by a third party provider canalso be deployed on the premises of the enterprise.

The resources of a private cloud are dedicated for use by users withinorganizations of the enterprise. A cloud can also be a hybrid cloud,which includes both a public cloud and a private cloud. Another type ofcloud is a managed cloud, which includes resources of the enterprisethat are managed by a third party provider.

More traditionally, an enterprise can deploy multiple data centers, suchas in different geographic regions (e.g. across a city, a state, acountry, or the world) to achieve redundancy, high availability (toensure availability of resources or to provide disaster recovery in caseof failure of a data center), or scalability (increasing resources tomeet increased demand). Deployment of multiple data centers can also befor satisfying government regulations (e.g. regulation specifying thatcertain data has to be kept in a specific country). These data centerscan be managed by the enterprise or by a third party provider. A datacenter can also provide services such as Software as a Service (SaaS)services. SaaS can refer to an arrangement in which software (or moregenerally, machine-executable instructions) is made available to userson a subscription basis.

Orchestrating workflows across different data centers can be associatedwith various challenges. For example, use of different data centers mayinvolve communications through many firewalls. As another example, thedata centers can be coupled over a network (such as the Internet) thatcan be associated with unexpected delays, packet losses, etc.,particularly during times of high usage. In such cases, guaranteeing thesatisfaction of target goals associated with a service level agreement(SLA) or quality of service (QoS) level can be difficult. Also, managingsecurity can be more complex. In addition, if cloud resources and/orSaaS services are employed, instances of applications that are to beorchestrated can be dynamically created, moved, replaced, and so forth,which can involve the use of dynamic addressing; as a result, it can bemore difficult to address such application instances.

The foregoing issues also exist when attempting to broker messagesreliably and with desired performance in a manageable manner across theInternet or among clouds. Legacy integration frameworks, such asEnterprise Service Bus (ESB) integration frameworks, also experience theforegoing challenges. A legacy integration framework can refer to anintegration framework different from that provided by the serviceexchange according to the present disclosure. ESB refers to anarchitecture model for designing and implementing communication betweenmutually interacting applications in a service-oriented architecture(SOA), where the applications can be distributed usually within a datacenter. While theoretically it is also possible to distributeapplication across the Internet or among clouds, that can be associatedwith issues relating to changing use cases and routing, dynamicaddressing, and message delivering in a manageable manner acrossInternet or data centers. The ESB framework provides for monitoring andcontrol of routing of message between applications, resolving contentionbetween applications, and other tasks.

The service exchange according to some implementations of the presentdisclosure is able to interact with an ESB integration framework oranother framework, e.g. with a message queue for exchanging messagesamong applications that would already be present to integrate theapplications.

In accordance with some implementations, techniques or mechanisms enablethe orchestrated execution of applications across multiple data centers.Additionally, the service exchange according to some implementationsenable cloud scale message brokering (to allow an exchange of messagesacross clouds) or a cloud event driven architecture (EDA). An EDA refersto a framework that orchestrates behavior around the production,detection and consumption of events as well as the responses the eventsevoke. A cloud EDA refers to such a framework implemented across clouds.

FIG. 1A illustrates an example arrangement that includes a data center100, a data center 102, and a data center 104. The data centers 100,102, and 104 can be enterprise data centers and/or clouds as discussedabove. Although just three data centers are shown in FIG. 1A, it isnoted that in other examples, different numbers of data centers can beprovided.

The data center 100 includes a service exchange 110, which includes anorchestrator 112, a message broker 114, and adapters 116. The adapters116 are provided between the message broker 114 and respectiveapplications 118. Although the applications 118 are depicted as beingpart of the service exchange 110 in FIG. 1A, it is noted that in otherexamples, the applications 118 can be separate from the service exchange110, and some applications 118 can even be external of the data center100. For example, some applications 118 can be provided by an entitythat is separate from the provider of the data center 100.

Each of the orchestrator 112, message broker 114, and adapters 116 canbe implemented as a combination of machine-executable instructions andprocessing hardware, such as a processor, a processor core, anapplication-specific integrated circuit (ASIC) device, a programmablegate array, and so forth. In other examples, any of the orchestrator112, message broker 114, and adapters 116 can be implemented with justprocessing hardware.

The message broker 114 is operatively or communicatively coupled to theorchestrator 112 and the adapters 116. Generally, the message broker 114is used to exchange messages among components, including theorchestrator 112 and the adapters 116. A message can include any or somecombination of the following: a call (e.g. API call) or an event (e.g.response, result, or other type of event). The message broker 114 isresponsible for ensuring that API calls and events (e.g. responses,results, etc.) are sent to the correct adapter or to the correctworkflow instance (multiple workflow instances may executeconcurrently). Alternatively, the endpoints (adapters and workflowinstances) may all receive a call or event and make a decision regardingwhether each endpoint should process the call or event.

The message broker 114 further includes a message confirmation engine(MCE) 119 to perform the following tasks. The message confirmationengine 119 ensures that a message put on the message broker 114 isdelivered to a target by checking for a confirmation of receipt of themessage by the target (e.g. an adapter 116), such as with a positiveacknowledgement, for example. Message confirmation is thus implementedwith the message broker 114 and the adapters 116. If the target does notconfirm receipt of the message, the message confirmation engine 119 cancause the message broker 114 to resend the message to the target.

The message confirmation engine 119 can also ensure that the targetprocesses the message (e.g. by checking that the target returns aconfirmation of commit). The confirmation of commit is an indication ofsuccessful completion of processing of the message. An application cansend the confirmation of commit, or alternatively, an adapter 116 canquery the application for the confirmation of commit. If theconfirmation of commit is not received, then the message confirmationengine 119 can cause the message broker to resend the message, or toindicate an error, depending on the type of message and application/flowdesign. Idempotent calls on the applications can be repeated as often asappropriate until commit is confirmed. When the calls cannot berepeated, error messages are sent and the workflow handles (in itslogic) what to do to perform rollback or notification. Rollback canrefer rolling back the workflow to a prior known good state.Notification can include notifying a management system (or managementsystems). The action to take in response to a lack of confirmation ofcommit can be determined from a canonical data model 117 (discussedfurther below).

The message confirmation engine 119 can also ensure that messages aredelivered in a managed manner (managed delivery of messages); in otherwords, messages are delivered without loss and with acceptable delays(delays within specified target levels). The message confirmation engine119 can also perform remediation if message loss or delays occur.Delivery times for messages can be monitored, and messages that are lostor excessively delayed (delayed longer than a specified target goal) arere-sent. Remediation can include resending the message that is missingor delayed to allow the endpoint to not have to wait anymore.Remediation can also include notifying other systems such as network ortraffic management systems to try to get more or better or alternatebandwidth, for example.

The message confirmation engine 119 can also perform securecommunication of messages with endpoints, by applying security to themessages. Applying security can include encryption of messages, mutualauthentication of messages, or use of certificates. Encryption of amessage is accomplished by using a key (e.g. public key or private key)to encrypt the message. Mutual authentication refers to the twocommunicating endpoints authenticating each other, such as with use ofcredentials or other security information. A certificate can be used toestablish a secure communication session between two endpoints.

To manage similar issues for communication of messages with the otherdata centers 102 and 104, a gateway 142 can also be provided in the datacenter 100. The gateway 142 is discussed further below, following thediscussion of operations of the orchestrator 112, the message broker114, and the adapters 116. If the other data center does not supportdeployment of a gateway and service exchange, then the gateway on theenterprise service exchange side can only do as much as it can withavailable protocols. In alternative examples, the remote cloud cansupport the same protocols or mechanisms of the gateway, or a gatewayand service exchange of a remote data center that is geographicallyclose to or collocated with the remote data center can be used tointeract with the cloud.

In addition, the message broker 114 is able to send a confirmation ofsuccessful completion of an application in a workflow to theorchestrator 112 or to a requester that initiated the workflow.

The orchestrator 112 is used to orchestrate the execution of a specificworkflow 113 that involves tasks performed by multiple applications(e.g. a subset or all of applications 118). To perform a workflow, flowlogic can be loaded into the orchestrator 112, and the flow logic isexecuted by the orchestrator 112. “Flow logic” can include arepresentation of a collection of tasks that are to be performed. Theflow logic can be in the form of program code (e.g. a script or otherform of machine-executable instructions), a document according to aspecified language or structure (e.g. Business Process ExecutionLanguage (BPEL),a Business Process Model and Notation (BPMN), etc.), orany other type of representation (e.g. Operations Orchestration fromHewlett-Packard, YAML Ain't Markup Language (YAML), Mistral fromOpenStack, etc.). The flow logic can be generated by a human, a machine,or program code, and can be stored in a machine-readable orcomputer-readable storage medium accessible by the orchestrator 112.

The orchestrator 112 is able to execute multiple flow logic to performrespective workflows. Multiple workflows and workflow instances(instances of a particular workflow refer to multiple instantiations ofthe particular workflow) can be concurrently executed in parallel by theorchestrator 112.

The orchestrator 112 is able to evaluate (interpret or execute) a flowlogic, and perform tasks specified by the flow logic in response to acurrent state of the workflow and calls and events received by theorchestrator 112. A workflow can be a stateful workflow. As a statefulworkflow is performed by the orchestrator 112, the orchestrator 112 isable to store a current state of the workflow, to indicate the portionof the workflow already executed. Based on the workflow's current stateand a received event, the orchestrator 112 is able to transition from acurrent state to a next state of the workflow and can determine a nextaction to perform, where the next action may involve the invocation ofanother application. Whenever the orchestrator 112 receives a new callor event (e.g. response, results, or other event), the orchestrator 112evaluates which workflow instance is to receive the call or event andloads the workflow instance with a correct state. In some cases, it ispossible that multiple workflow instances may check if they are supposedto be a recipient of a call or event.

In other examples, a workflow can be a stateless workflow, which doesnot keep track of a current state of the workflow. Rather, the statelessworkflow performs corresponding next steps or actions as events arereceived by the orchestrator 112. Use of a stateless workflow isgenerally suitable for asynchronous operation (discussed further below).A stateful workflow can be used with both a synchronous operation andasynchronous operation.

The events (e.g. results, responses, etc.) received by the orchestrator112 can be provided by applications that are invoked in the workflow orfrom another source, such as through an interface 115 (e.g. anapplication programming interface (API)) of the message broker 114. Themessage broker 114 can also direct an event to a particular workflowinstance (note that there can be multiple workflow instances executingconcurrently). If the workflow instance is a stateful workflow, then anevent can be provided to a state of the workflow.

An external entity can communicate with the message broker 114 using theAPI 115, such as to trigger a workflow (enterprise process or use case)or make progress (or step through) the workflow. The API 115 of themessage broker can also be used to communicate a status update of aworkflow.

The message broker 114 can include queues for temporarily storinginformation to be forwarded target components, and can includeinformation forwarding logic that is able to determine a destination ofa unit of information based on identifiers and/or addresses contained inthe unit of information.

In some examples, the message broker 114 can employ an Advanced MessageQueuing Protocol (AMQP), which is an open standard application layerprotocol for message-oriented middleware. AMPQ is described in aspecification provided by the Organization for the Advancement ofStructured Information Standards (OASIS). An example of a message brokerthat employs AMPQ is RabbitMQ, which is an open source message brokerapplication.

In other examples, other types of message brokers that employ othermessaging or information exchange protocols can be used.

The information exchanged using the message broker 114 can includeinformation sent by the orchestrator 112, where the information sent bythe orchestrator 112 can include applications calls and/or data. An“application call” can refer to a command (or commands) or any othertype of message that is issued to cause an instance of a respectiveapplication to execute to perform a requested task (or tasks).

The information exchanged using the message broker 114 can also includeinformation sent by the applications. For example, the information sentby an application can include response information that is responsive toa respective application call. The information sent by the applicationscan also include information sent autonomously by an application withouta corresponding request from the orchestrator 112. Information from anapplication can be included in an event sent by the application, wherean “event” can refer to a representation of a unit of information. Theevent can include a response, a result, or any other information. Notethat an event from an application can be in response to a synchronouscall or asynchronous call. A synchronous call to an application by theorchestrator 112 is performed for a synchronous operation. In asynchronous operation, a workflow waits for a response to be receivedbefore proceeding further (in other words, the workflow blocks on theresponse). An asynchronous operation of a workflow refers to anoperation in which the workflow does not wait for a response from anapplication in response to a call to the application.

In other examples, an event from an application can be due to somethingelse occurring at the application level or in the environment (e.g. asupport agent closes a ticket when using the application). Such an eventcan be sent to the workflow, such as the workflow for an incident caseexchange use case (explained further below).

An event or call can also be received through the API 115 of the messagebroker 104 from another source.

The message broker 114 is able to respond to a call (such as an API callfrom the orchestrator 112 by making a corresponding call to the API ofthe respective instance of an application that is executing in aparticular workflow instance. Adapters 116 may register with the messagebroker 114, and the message broker 114 can use the registration todetermine how to direct a call, and how events (e.g. results, responses,etc.) are tagged or associated to a workflow instance. In some cases, itis possible that a message (a call or event) may be addressed to severalworkflow instances, in which case the message broker 114 can direct themessage to the several workflow instances.

When performing a workflow based on flow logic executed by theorchestrator 112, the orchestrator 112 can issue application(synchronous or asynchronous) calls to the message broker 114 forinvoking the applications at corresponding points in the workflow. Acall can also be made by the orchestrator as part of throwing an event(which refers to the workflow deciding to communicate the event as aresult of some specified thing occurring).

The flow logic for a respective workflow can be written abstractly usinga canonical data model (CDM) 117. Although the canonical data model 117is depicted as being inside the message broker 114, it is noted that thecanonical data model 117 can be separate from the message broker 117 inother examples.

The canonical data model 117 can be used to express application calls tobe issued by the orchestrator 112 to the message broker 114. Thecanonical data model 117 can also be used to express arguments (e.g.messages) for use in the calls, as well as the logic to be performed.The application calls can be abstract calls. The canonical data model117 can be expressed in a specific language, such as a markup languageor in another form.

More generally, a flow logic is written according to the canonical datamodel 117 can represent the following: arguments that are beingexchanged in interactions of the applications, the functions that arecalled to support the interactions, the events (e.g. responses, results,or other events) that can result, any errors that can arise, and statesof the use case executed across the applications. In general ad-hoc datamodels can be used but they may change whenever a new use case isintroduced or when an application changes. According to implementationsof the present disclosure, the canonical data model 117 can be beendefined across a large number of use cases representative of therelevant interactions that can take place in a particular domain (suchas IT management or another domain) and across a wide set ofapplications that can be used to support subsets of the use cases. Thus,in general, a canonical data model can be shared across use cases of aparticular domain. A different canonical data model can be used for usecases of another domain. If a use case involves applications indifferent domains, then a canonical data model can be expanded tosupport the other domain, or multiple canonical data models may be used.

The information representing interactions between applications and theinformation representing the states of the applications can be used totrack a current state of a workflow (assuming a stateful workflow). Theinformation regarding the errors in the canonical data model 117 can beused for handling errors that arise during execution of theapplications. The information regarding the errors can be used to map anerror of an application to an error of the workflow that is beingperformed by the orchestrator 112

By using the canonical data model 117, the development of flow logicthat is valid across large sets of applications can be achieved. Sharinga data model across the flow logic can facilitate combining the flowlogic and/or customizing the flow logic, and also allows for adapters tobe changed or modified to replace applications.

In other implementations, the service exchange 110 does not employ thecanonical data model 117, but rather development of the flow logic canbe ad-hoc (such as by use of the ad-hoc models noted above) for each usecase and/or set of applications.

The application calls issued by the orchestrator 112 can be sent throughan interface between the orchestrator 112 and the message broker 114. Inthis way, the expression of the flow logic does not have to be concernedwith specific data models or interfaces employed by the applications,which simplifies the design of the orchestrator 112.

Also, the orchestrator 112 does not have to know specific locations ofthe applications—the applications can be distributed across multipledifferent systems in disparate geographic locations. The message broker114 is responsible for routing the application calls to the respectiveadapters 116.

Information communicated between the message broker 114 and the adapters116 is also in an abstract form according to the canonical data model.For example, the message broker 114 can forward an abstract applicationcall from the orchestrator 112 to a respective adapter. Similarly, anadapter can send an event from an application to the message broker inan abstract form according to the canonical data model.

The adapters 116 perform protocol translations between the protocol ofthe abstract API of the message broker 114, and the protocols to whichthe interfaces exposed by the corresponding applications are bound. Asan example, the protocol of the abstract API of the message broker 114can be according to a Representational State Transfer (REST) protocol orsome other protocol. The protocol of an interface exposed by anapplication can include Simple Object Access Protocol (SOAP), RemoteProcedure Call (RPC), Session Initiation Protocol (SIP), and so forth.

Each adapter 116 can also transform the data model of a message (e.g.message carrying an event) and an abstract API call to the data modeland specific API call exposed by a particular application (e.g. instanceor release of the particular application). Stated differently, theadapter 116 performs interface adaptation or interface translation byconverting the abstract message or abstract API to a message or API callthat conforms to the API of the target application. The reverseconversion is performed in the reverse direction, where the result,response, event, message or API call from an application is converted toan abstract message or abstract API call that can be passed through themessage broker 104 to the orchestrator 112.

Each adapter 116 can also perform address translation between an addressin the address space used by the orchestrator 112 and the message broker114, and an address in the address space of an application.

The service exchange 110 provides for a multi-point orchestratedintegration across multiple applications. The multi-point orchestratedintegration can include the applications 118 associated with the datacenter 100 as well as applications or services of the other data centers102 and 104.

In the example according to FIG. 1A, the workflow 113 executed by theorchestrator 112 of the service exchange 110 can thus involve bothprocesses of applications 118 associated with the data center 100, aswell as processes of applications of the data center 102 and services140 (e.g. SaaS services) in the data center 104.

The data center 102 also includes a service exchange 130 that can have asimilar arrangement as the service exchange 110 of the data center 100.

The service exchange 130 can include or be associated with applications138. Execution of the applications 138 can provide the services 120 ofthe data center 102 shown in FIG. 1A.

The service exchange 130 includes an orchestrator 132 that can execute aworkflow 133, a message broker 134 that includes a message confirmationengine (ME) 139 and a canonical data model 137 (similar to the messageconfirmation engine 119 and the canonical data model 117 in the messagebroker 114), and adapters 136. The message broker 134 also has aninterface 135 similar to the interface 115 of the message broker 114.

The workflow 133 executed by the orchestrator 132 in the serviceexchange 130 of the data center 102 can also involve applications andservices across multiple data centers.

In some examples, the data center 104 does not include a serviceexchange similar to service exchange 110 or 130, but instead includes adifferent infrastructure for deploying the services 140. In general, aservice exchange does not exist in any data center (including servicesand/or applications to be orchestrated) that is provided by a providerdifferent from the enterprise that provides the data centers 100 and102, for example. In such situations, techniques as discussed furtherabove where the remote data center is without a gateway can be applied.

In examples according to FIG. 1A, an orchestrator 112 or 132 canorchestrate execution of a workflow that includes selected applicationsor services, including the applications 118, the applications 138, andthe SaaS services 140.

As further shown in FIG. 1A, the data center 100 and data center 102each includes a respective gateway 142 and 144. Although the gateways142 and 144 are shown outside the respective service exchanges 110 and130, it is noted that the gateways 142 and 144 can also be considered tobe part of the respective service exchanges 142 and 144. Each gateway142 or 144 includes a bridge between communications of the respectiveservice exchange 110 or 130 (more specifically the communications of therespective message broker 114 or 134) and communications over a network146, which can be a public network such as the Internet.

Communications over the network 146 can be according to a specifiedprotocol, such as the Hypertext Transfer Protocol (HTTP), WebSocketprotocol, Representational State Transfer (REST) protocol, or any otherprotocol.

As further shown in FIG. 1B, each gateway 142 or 144 includes a protocoltranslator 150 that can convert between the protocol used by therespective message broker 114 or 134, and the protocol used over thenetwork 146.

For orchestration of applications within a single data center (such as100 or 102), information exchange can be accomplished using therespective message broker 114 or 134, without involving the gateway 142or 144. Moreover, for communications within just one data center, packetloss and delay and/or security of messages may not be a concern, sincethe communications occur within the same data center.

However, for communications over among different data centers (e.g.across clouds) or over the Internet, then message loss and delay and/ormessage security can become a concern. The gateways 142 and 144 areprovided to address the foregoing issues and possibly issues associatedwith confirmation of message delivery and message processing commit, asdiscussed above.

In some examples, the message confirmation engine 119 or 139 of themessage broker 114 or 134 can be used to ensure that a message isdelivered to a target by checking for confirmation of receipt of themessage by the target, and to ensure that the target has returned aconfirmation of commit. In other examples, the gateway 142 or 144 caninclude a message confirmation engine 154 to perform the foregoingtasks, and can perform resending of a message in response to notreceiving a confirmation of receipt of the message, and resending themessage or indicating an error in response to not receiving aconfirmation of commit.

As further discussed above, the message confirmation engine 119 or 139in the message broker 114 or 134 can also ensure that messages aredelivered in a managed manner; in other words, messages are deliveredwithout loss and with acceptable delays (delays within specified targetlevels). The message broker 114 or 134 can also perform remediation ifmessage loss or delays occur. Delivery times for messages can bemonitored, and messages that are lost or excessively delayed (delayedlonger than a specified target goal) are re-sent. Also, managementsystems can be notified as appropriate.

The message confirmation engine 154 in the gateway 142 or 144 canperform managed delivery of messages in lieu of or in addition to thatperformed by the message confirmation engine 119 or 139 of the messagebroker 114 or 134.

As noted above, the message confirmation engine 119 or 139 can alsoperform secure communication of messages with endpoints, such as byemploying encryption of messages, mutual authentication of messages, oruse of certificates.

In addition to or in lieu of performing security for messages by themessage broker 114 or 134 across the network 146, a security engine 152of the gateway 142 or 144 can perform the respective tasks, which caninclude message encryption, mutual authentication, or security using acertificate.

The gateway 142 or 144 can implement protocol changes and capabilitiesto perform the foregoing. For example, the gateway 142 or 144 canimplement a mechanism to number and timestamp messages or packets(carrying the messages) that are sent to target endpoints over thenetwork 146. For example, sequence numbers that monotonically increasecan be assigned to messages (or packets) as they are sent to the targetendpoint. The sequence numbers can be used to identify which data units(message or packets) were not received (i.e. lost). The gateway 142 or144 can also determine the time for delivery and receipt of messagessent to the target endpoints. If the time taken to deliver a data unit(message or packet) exceeds a target goal, then the data unit can bere-sent. In some examples, bi-directional Hypertext Transfer Protocol(HTTP) communications (such as according to the WebSocket protocol) canbe established between gateways 142 and 144 with packet numbering andtimestamps (that indicate when a packet was sent). The bi-directionalHTTP communications include a return channel through which a receiver isable to provide feedback regarding delays or data loss. The WebSocketprotocol supports adding extensions such as packet numbers andtimestamps in a standardized manner.

For the data center 104, managed communications of messages can beaccomplished in the following manner. In some examples, the SaaSservices 140 can expose APIs and protocols that are compatible with theuse of packet numbering and timestamping by the gateways 142 and 144.For example, the SaaS services 140 can employ a Websocket protocol thatemploys packet numbering and timestamps, or some other mechanism. Inthis way, the gateways 142, 144 can interact with the SaaS services 140to perform managed delivery of messages.

In other examples, managed delivery of messages with the SaaS services140 is accomplished using just the gateway 142 or 144 on one side. Ifthe remote data center 104 does not support deployment of a gateway andservice exchange (e.g. because the data center belongs to other entity),then the gateway 142 on the enterprise service exchange side can only doas much as it can with available protocols. In alternative examples, theremote data center 104 can support the same protocols or mechanisms ofthe gateway 142. Examples of implementing same behavior at the SaaSlevel would be if the SaaS APIs were bounded to WebSocket with sameextensions. In other examples, a gateway and service exchange of anotherdata center that is geographically close to or collocated with the datacenter 104 can be used to interact with the data center 104.

To implement security, the gateway 142 or 144 can performsecurity-related tasks for messages in addition to or in lieu of thesecurity-related tasks performed by the message broker 114 or 134discussed above. As discussed above, these security-related tasksinclude encryption of messages, mutual authentication of messages, oruse of certificates. For communications with the SaaS services 140 wherejust one gateway 142 or 144 is present, then encryption andauthentication as supported by SaaS services 140 can be employed.

In other examples, a respective gateway can also be included in the datacenter 104.

The latency associated with communications over the network 146 cancause delays in the use case progress and impact the user experience andQoS experienced. Also, faults or errors in the network 146 may causecertain information to be lost, so that reliable communications may notbe readily available over the network 146. A workflow provided by theservice exchange 110 or 130 may be associated with a target performancegoal, or more simply, a target goal. Examples of a target goal caninclude any of the following: target maximum response time from arequest, target maximum usage of resources, target maximum error rate,and so forth. The target goal can be specified in a service levelagreement (SLA) and can specify a maximum allowable delay between a callfrom the orchestrator and a response from a target application orservice. In other examples, the target goal can be associated with a QoSlevel that is specified for the workload, either by agreement or someother mechanism.

FIG. 2 shows an example of the service exchange 110 with a managementengine 202 according to some implementations. The management engine 202can be implemented with a combination of machine-executable instructionsand processing hardware, or with just processing hardware. Themanagement engine 202 can be separate from the message broker 114, orcan be part of the message broker 114.

The service exchange 110 includes the orchestrator 112 and messagebroker 114 as discussed above. Also, the service exchange 110 includesadapters 116-1 to 116-N (N>1) that are provided between the messagebroker 114 and respective applications 118-1 to 118-N.

The management engine 202 includes a performance monitor 112 that canmonitor the performance of a workflow that is executed by theorchestrator 112. The management engine 202 also is able to access adatabase 206 that stores information relating to target goals 208associated with respective workloads that can be executed by theorchestrator 112, where the target goals can be specified by an SLA or aQoS level. The database 206 can also store metrics and thresholds.

According to the examples described above, the performance monitor 112can detect a time when a request is received to initiate a workflow. Inresponse to the request, the performance monitor 112 can measure theamount of time that has passed since the time the request was received.The performance monitor 112 can retrieve information relating to atarget goal associated with the workflow. The performance monitor 112can compare the elapsed time with the target goal to determine whetherexecution of the workflow will satisfy a target maximum time durationspecified by the respective target goal. If not, the performance monitor112 can issue an indication to a handler 210 of the management engine202 to handle the potential violation of the target goal to performremediation.

In some examples, in a workflow that includes multiple tasks, the targetgoal can specify the maximum time duration from when task i (of anapplication of any of multiple data centers) begins to when task i isexpected to complete. The performance monitor 204 is able to compare theelapsed execution time for task i with the maximum time duration of thetarget goal. If violation of the maximum time duration has or ispredicted to occur, then the performance monitor 204 issues anindication to the handler 210, which can take action to resolve theissue. For example, the handler 210 can cause additional computingresources to be allocated to the workflow, so that the workflow canexecute at a faster rate to meet the target goal.

The performance monitor 204 can also monitor for other events associatedwith the workflow. For example, the performance monitor 204 candetermine the error rate associated with execution of the workflow, orcan determine the amount of resources used by the execution of theworkflow. If the error rate or resource usage exceeds a specifiedthreshold (e.g. a threshold error rate or a threshold resourceconsumption), then the performance monitor 204 can issue a respectiveindication to cause the handler 210 to take a corresponding action, suchas to allocate a different set of resources to execute the workflow (ifa currently allocated set of resources is causing an excessive errorrate), or to reduce an allocation of resources (if the workflow isconsuming an excessive amount of resources).

FIG. 3 shows an example in which the service exchange 110 according tosome implementations of the present disclosure is able to interact witha legacy integration framework 302, such as an ESB framework (asdiscussed above), a Schools Interoperability Framework (SIF), or anyother integration framework that is a different type of integrationframework from the service exchange 110. SIF includes a specificationfor modeling data, and a Service-Oriented Architecture (SOA)specification for sharing data between institutions.

The legacy integration framework 302 integrates applications 304, suchas according to enterprise architecture integration (EAI). A gateway 306is provided between the legacy integration framework 302 and the serviceexchange 110 to perform protocol translation 308 and interfacetranslation 310 between the interface 115 of the service exchange 110and the interface 312 to the legacy integration framework 302.

The protocol translation 308 and interface translation 310 can besimilar to the protocol and interface translations applied by theadapters 116 of the service exchange 110, except that the protocoltranslation 308 and interface translation 310 are to provide adaptationto the legacy integration framework 302 and to the applications 304integrated by the legacy integration framework 302.

Although not shown, a bridge can also be provided between the serviceexchange 110 and the legacy integration framework 302 if the serviceexchange 110 and the legacy integration framework 302 are in differentdata centers. The bridge can include gateways similar to the gateways142 and 144 at each end discussed above.

FIG. 3 also shows a portal 314. Note that a portal can also be providedin implementations according to FIGS. 1 and 2. The portal 314 is anexample of an entity interacting with the API 105 for triggeringworkflows or of orchestrated applications. Although FIG. 3 shows theportal 314 as using the message broker 104, it is noted that the portal314 can also be one of the applications orchestrated through arespective adapter 116.

In some examples, the portal 314 can present a user interface (UI). Theportal 314 can include machine-executable instructions or a combinationof machine-executable instructions and processing hardware. The portal314 can be at a computer (e.g. client computer) that can be remote fromthe service exchange 110. The UI allows a user to interact with theservice exchange 110.

A user can perform an action in the UI that triggers the execution of aflow logic (of multiple different flow logic) by the orchestrator 112 toperform a workflow.

An indication of user action in the UI (e.g. an action to order an itemor service) can be communicated to the orchestrator 112 and thecorresponding workflow by the portal 314 and the message broker 114. Theindication can be communicated using the API 105 (e.g. REST API) of themessage broker 114.

This indication of user action received by the message broker 114 can becommunicated to the orchestrator 112, which invokes execution of thecorresponding flow logic to perform the requested workflow.

FIG. 4 is a flow diagram of a process performed by a service exchange(e.g. 110 or 130).

An orchestrator (e.g. 112 or 132) of the service exchange in a firstdata center executes (at 402) a workflow that is associated with atarget performance goal, where the workflow includes tasks ofapplications of the first data center and of a second data center.

During the executing of the workflow, information is communicated (at404) between the orchestrator and the processes of the applicationsthrough a message broker (e.g. 114 or 134) of the service exchange.

Adapters (e.g. 116 or 136) of the service exchange perform (at 406)protocol and interface translations for information communicated betweenthe message broker and the applications in the first data center.

A management engine (e.g. 202) monitors (at 408) performance of theworkflow to determine whether the executing of the workflow is able tomeet the target goal.

Content of the service exchange platform including the orchestrator, themessage broker, and the adapters can be changed, such as from anadministration system coupled to the service exchange. Applications canbe changed, flow logic can be changed, and use cases can be created.

Any given application can be updated or replaced, simply by replacing ormodifying the corresponding adapter. For example, if an enterprisewishes to upgrade or replace a given application (with a new applicationor an updated version of the given application), then the correspondingadapter to which the given application is coupled can be replaced orupdated to support the updated or replaced application. In some cases,replacing the given application can involve replacing a firstapplication supplied by a first vendor with a second applicationsupplied by a different vendor. In other cases, replacing the givenapplication can involving replacing a first application supplied by avendor with another application supplied by the same vendor. As yetanother example, replacing the given application can include upgradingthe application to a new release.

Changing a given adapter can involve removing a representation of theadapter (which can be in the form of program code, a markup languagefile, or some other representation), and replacing the removedrepresentation of the adapter with a new representation of a differentadapter. Changing the given adapter can alternatively involve modifyingthe given adapter or modifying a configuration of the given adapter tosupport the different application. The changing of the given adapter canbe performed by a machine or by program code, either autonomously (suchas in response to detection of a replacement of an application) or inresponse to user input.

Changing an application may also involve moving an instance of theapplication from one instance to another instance, or from one locationto another location. The respective adapter can be updated orconfiguration of the adapter is changed (the adapter itself remainsunchanged), to refer to another application instance or to an instanceof the application at another location.

When changing an application to a new or updated application, it may bepossible that certain functionality of the previous application is nolonger available from the new or updated application. In this case, therespective adapter can delegate or orchestrate with another application(or web service) that provides the missing functionality. Alternatively,the workflow can be modified to take into account the loss offunctionality in the use case.

Also if new functionality is provided by new or upgraded application,the workflow can be modified to use the new functionality.

In accordance with some implementations, a workflow can be modifiedrelatively easily by changing the respective flow logic with a differentflow logic (a modified version of the flow logic or a new flow logic).The different flow logic can then be loaded onto the orchestrator toimplement the modified workflow. By using the service exchange,workflows can be easily customizable by providing new or modified flowlogic to the orchestrator. Nothing else has to be changed unless a newuse case specifies use of new calls and data not covered in currentadapters (e.g. an adapter is able to call just a subset of APIs of theapplication) or the canonical model. In this latter case, the canonicaldata model can be updated and adapters can be updated to be able to makethe calls, or new adapters can be provided.

New use cases can also be created, and corresponding flow logic andadapters can be provided. In addition, the canonical data model may beupdated accordingly.

The content changes noted above can be performed using any of varioustools, such as a Software Development Kit (SDk) tool or other type oftool used to create applications and other program code. A content packcan be updated using the tool, and the modified content pack can beloaded using an administration system. The administration system canconfigure the adapters to point to the correct instance of anapplication. A new use case and respective content can be also createdwith an SDk tool. Note also that when the canonical data model 107 isupdated, the canonical data model 107 remains backwards compatible withcontent packs of existing use cases.

FIG. 5 is a block diagram of an example computer system 500 according tosome implementations, which can be used to implement the serviceexchange 110 or 130 according to some implementations. The computersystem 500 can include one computer or multiple computers coupled over anetwork. The computer system 500 includes a processor (or multipleprocessors) 502. A processor can include a microprocessor, amicrocontroller, a physical processor module or subsystem, aprogrammable integrated circuit, a programmable gate array, or anotherphysical control or computing device.

The processor(s) 502 can be coupled to a non-transitory machine-readableor computer-readable storage medium 504, which can store variousmachine-executable instructions. The machine-executable instructions caninclude orchestration instructions 506 to implement the orchestrator 112or 132, message broker instructions 508 to implement the message broker114 or 134 (including the message broker application 410 and eventhandlers 414 shown in FIG. 3), adapter instructions 510 to implement theadapters 116, management engine instructions 512 to implement themanagement engine 202 (including the performance monitor 204 and thehandler 210), and message confirmation instruction 514 to implement themessage confirmation engine 119 or 139.

The storage medium (or storage media) 504 can include one or multipleforms of memory including semiconductor memory devices such as dynamicor static random access memories (DRAMs or SRAMs), erasable andprogrammable read-only memories (EPROMs), electrically erasable andprogrammable read-only memories (EEPROMs) and flash memories; magneticdisks such as fixed, floppy and removable disks; other magnetic mediaincluding tape; optical media such as compact disks (CDs) or digitalvideo disks (DVDs); or other types of storage devices. Note that theinstructions discussed above can be provided on one computer-readable ormachine-readable storage medium, or alternatively, can be provided onmultiple computer-readable or machine-readable storage media distributedin a large system having possibly plural nodes. Such computer-readableor machine-readable storage medium or media is (are) considered to bepart of an article (or article of manufacture). An article or article ofmanufacture can refer to any manufactured single component or multiplecomponents. The storage medium or media can be located either in themachine running the machine-readable instructions, or located at aremote site from which machine-readable instructions can be downloadedover a network for execution.

In the foregoing description, numerous details are set forth to providean understanding of the subject disclosed herein. However,implementations may be practiced without some of these details. Otherimplementations may include modifications and variations from thedetails discussed above. It is intended that the appended claims coversuch modifications and variations.

What is claimed is:
 1. A system comprising: a service exchangecomprising: an orchestrator to execute a workflow that involves aplurality of applications and services of a plurality of data centers; amessage broker to exchange messages that comprise a call from theorchestrator to at least one of the applications and the services, andthe orchestrator to react to an event or call from the at least oneapplication or service; and adapters to perform protocol and interfacetranslations for information communicated between at least some of theapplications and the message broker.
 2. The system of claim 1, whereinthe message broker is to check for confirmation of receipt of a givenmessage from a target to which the given message is sent, and to causeresending of the given message in response to failure to receive theconfirmation of receipt.
 3. The system of claim 2, wherein the messagebroker is to receive the confirmation of receipt of the given messagefrom one of the adapters.
 4. The system of claim 1, wherein the messagebroker is to check for confirmation of commit of processing of a givenmessage from a target to which the given message is sent, and to causeresending of the given message or indicating an error in response tofailure to receive the confirmation of receipt.
 5. The system of claim4, wherein the message broker is to further perform rollback ornotification of at least one management system in response to failure toreceive the confirmation of receipt.
 6. The system of claim 1, whereinthe message broker is to check for loss or delay of the given message,and to perform remediation in response to detecting the loss or thedelay of the given message.
 7. The system of claim 1, wherein themessage broker is to apply security to a message communicated to atarget.
 8. The system of claim 1, wherein the service exchange is partof a first data center of the plurality of data centers, and the serviceexchange further comprising a gateway to communicate over a network witha second data center of the plurality of data centers, the gateway toconvert between a protocol used by the message broker and a protocolused over the network.
 9. The system of claim 8, wherein the gateway isto check for loss or delay of a given message sent over the network, andto perform remediation in response to detecting the loss or the delay ofthe given message.
 10. The system of claim 9, wherein the gateway is toadd numbers and timestamps to messages or packets according toextensions supported by a WebSocket protocol.
 11. The system of claim 8,wherein the gateway is to apply security to a message communicated to atarget over the network.
 12. The system of claim 1, wherein the messagebroker is to communicate interact through a gateway with an integrationframework.
 13. The system of claim 12, wherein the integration frameworkis selected from among an Enterprise Service Bus (ESB) framework and aSchools Interoperability Framework (SIF).
 14. The system of claim 1,wherein the service exchange is part of a first data center of theplurality of data centers, and wherein services of a second data centerof the plurality of data centers comprise software as a service (SaaS)services.
 15. The system of claim 1, further comprising a managementengine to manage a target goal associated with communications with theapplications and the services across the plurality of data centers. 16.The system of claim 15, wherein the target goal specifies a target timeduration goal for communication with an application or service.
 17. Thesystem of claim 15, wherein the target goal is specified by a servicelevel agreement or a quality of service.
 18. A method comprising:executing, by an orchestrator of a service exchange in a first datacenter, a workflow that is associated with a target performance goal,the workflow comprising tasks of applications of the first data centerand of a second data center; communicating, during the executing of theworkflow, information between the orchestrator and the processes of theapplications through a message broker of the service exchange;performing, by adapters of the service exchange, protocol an interfacetranslations for information communicated between the message broker andthe processes of the applications in the first data center; andmonitoring, by a management engine, performance of the workflow todetermine whether the executing of the workflow is able to meet thetarget performance goal.
 19. The method of claim 18, wherein monitoringthe performance of the workflow comprises determining whether theexecuting of the workflow is able to satisfy a time duration goal of theworkflow.
 20. The method of claim 18, wherein monitoring the performanceof the workflow comprises determining whether the executing of theworkflow is able to satisfy an error rate goal or a resource consumptiongoal of the workflow.
 21. An article comprising at least onenon-transitory machine-readable storage medium storing instructions thatupon execution cause a system to: execute, by an orchestrator of aservice exchange in a first data center, a workflow, the workflowcomprising tasks of applications across a plurality of data centers, atleast one of the data centers comprising a cloud of resources;communicate, during the executing of the workflow, information betweenthe orchestrator and the processes of the applications through a messagebroker of the service exchange; checking, by the message broker, forconfirmation of receipt and for confirmation of commit of processing ofa given message sent to a target; performing a remediation action inresponse to failing to receive the confirmation of receipt or theconfirmation of commit; and perform, by adapters of the serviceexchange, protocol and interface translations for informationcommunicated between the information broker and at least some of theapplications.